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Figure 1: The syntax of CSN. 
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This section addresses the syntax and the semantics of the Calculus for 
Sensor Networks. The syntax of the calculus is given by the grammar in Figure 
[TJ The calculus encompasses a two-level structure: networks and programs. 

Networks N are flat, unstructured collections of sensors and values. 

A sensor [P, M]^'^ represents an abstraction of a physical sensing device 
located at position p and running program P. Module M is the collection 
of methods that the sensor makes available for internal and for external us- 
age. Typically this collection of methods may be interpreted as the library of 
functions of the tiny operating system installed in the sensor. Sensors may only 
broadcast values to its neighborhood sensors. Radius rt defines the transmitting 
power of a sensor and specifies the border of communication: a circle centered 
at position p (the position of the sensor) with radius rt- Likewise, radius 
defines the sensing capability of the sensor, meaning that a sensor may only 
read values inside the circle centered at position p with radius r^ . 

Values {v)P define the field of measures that may be sensed. A value consists 
of a tuple V denoting the strength of the measure at a given position p of the 
plane. Values are managed by the environment; in CSN there are no primi- 
tives for manipulating values, besides reading (sensing) values. We assume that 
the environment inserts these values in the network and update its contents. 
Networks are combined using the parallel composition operator | . 
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Processes are built from the inactive process idle and from ... idle denotes 
a terminated thread. 

and sensing values from the environment sensed th 

Programs P and Q may be combined in sequence, P ; Q, or in parallel, P \ Q. 
The sequential composition P ; Q designates a program that first executes P 
and then proceeds with the execution of Q. In contrast, P \ Q represents the 
simiiltaneous execiition of P and Q. However we consider that sensors support 
only a very limited form of parallelism; P and Q do not interact during their 
execution; 

Mutually recursive method definitions makes possible to represent infinite 
behaviours. 

Values are the data exchanged between sensors, and are basic values b, 
method labels I, positions p, and modules M. Notice that the calculus in not 
high-order in the sense that communication of modules ... 

As an example, consider a... 

1 Programming Examples 

In this section we present some examples, programmed in CSN, of typical oper- 
ations performed on networks of sensors. Our goal is to show the expressiveness 
of the CSN calculus just presented and also to identify some other aspects of 
these networks that may be interesting to model. In the following examples, 
we denote as MSensor and MSink the modules installed in any of the anonymous 
sensors in the network and the modules installed in the sink, respectively. Note 
also that all sensors are assumed to have a builtin method, deploy, that is re- 
sponsible for installing new modules. The intuition is that this method is part 
of the tiny operating system that allows sensors to react when first placed in the 
field. Finally, we assume in these small examples that the network layer sup- 
ports scoped flooding. We shall see in the next section that this can be supported 
via software with the inclusion of state in sensors. 

1.1 Ping 

We start with a very simple ping program. Each sensor has a ping method that 
when invoked calls a method forward in the network with its position and battery 
charge as arguments. When the method forward is invoked by a sensor in the 
network, it just triggers another call to forward in the network. The sink has 
a distinct implementation of this method. Any incomming invocation logs the 
position and battery values given as arguments. So, the overall result of the 
call net. ping [] in the sink is that all reachable sensors in the network will, in 
principle, receive this call and will flood the network with their positions and 
battery charge values. These values eventually reach the sink and get logged. 

MSensor(p , b) = { 

ping = () net . f o r wa rd [ p , b ] ; net . ping [] 

forward = (x,y) net . forwa rd [x , y ] 
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M{li) = {Xi)Pi b > Cin 



(R-method) 
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Figure 2: Reduction semantics for processes and networks. 



} 

MSink(p,b) = { 

forward = (x,y) log_position _a nd_power [x , y ] 

} 

[net.ping[] , MSink(p,6)] ^ I 

[idle, MSensor(pi,6i)] fi''-! | ... | [idle, M Sensor ] 



1.2 Querying 

This example shows how we can program a network with a sink that period- 
ically queries the network for the readings of the sensors. Each sensor has a 
sample method that samples the field using the sense construct and calls the 
method forward in the neighbourhood with its position and the value sampled as 
arguments. The call then queries the neighbourhood recursively with a replica 
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of the original call. The original call is, of course, made from the sink, which 
has a method start_sample that calls the method sample in the network within a 
cycle. Note that, if the sink had a method named sample instead of start_sample, 
it might get a call to sample from elsewhere in the network that could interfere 

with the sampling control cycle. 

MSensor(p) = { 

sample = () sense (x) in net . forwa rd [ p , x]; net.sample[] 

forward = (x, y) net . forwa rd [x , y ] 

} 

MSink(p) = { 

start-sample = () net . sample [] ; t h is . sta rt _sa m p I e [] 

forward = (x, y) log_posi t lo n _a n d _va I u e [x , y ] 

} 

[this, start _s ample [] , MSink(p)] f | 

[idle, MSensor(/;i)] | ... | [idle, M Sensor (/;„)] I,';; '" 



1.3 Polling 

In this example the cycle of the sampling is done in each sensor, instead of in the 
sink, as in the previous example. The sink just invokes the method start_sample 
once. This method propagates the call through the network and invokes sample, 
for each sensor. This method samples the field, within a cycle, and forwards the 
result to the network. This implementation requires less broadcasts than the 
previous one as the sink only has to call start_sample on the network once. On 
the other hand, it increases the amount of processing per sensor. 

MSensor(p) = { 

start_sample = () net . sta rt _sa m p le [ ] ; this . sample [] 

sample = () sense (x) in net . forwa rd [ p , x]; this . sample [] 

forward = (x, y) net . forwa rd [x , y] 

} 

MSink(p) = { 

forward = (x, y) I og_posi t io n _a n d _va I u e [x , y ] 

} 

[ net . sta rt_exa m p le [] , MSink(j5)] | 

[idle, MSensor(pi)] ^i'"! j ... | [idle, MSensor (p„) ] ^J^'"" 



1.4 Code deployment 

The above examples assume we have some means of deploying the code to 
the sensors. In this example we address this problem and show how it can be 
programmed in CSN. The code we wish to deploy and execute is the same as the 
one in the previous example. To achieve this goal, the sink first calls the deploy 
method on the network to install the new module with the methods start_sample , 
sample and forward as above. This call recursively deploys the code to the sensors 
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in the network. The sink then calls start_sample to start the sampling, again as 
above, and waits for the forwarded results on the method forward. 

MSensor(p) = { 

deploy = (x) install x; net . deploy [x] 

} 

MSink(p) = { 

forward = (x,y) log_posi t lo n _a n d _va I u e [x , y ] 

} 

[ net . deploy [{ 

start-sample = () net . st a rt _sa m p le [ ] ; this . sample [] 

sample = () sense (x) in net . forwa rd [ p , x]; this . sample [] 

forward = (x, y) net . forwa rd [x , y] 

}]; 

net . start .sample [] , MSink(p)] | 
[idle, MSensor(pi)] ^^^■'•1 | ... | [idle, MSensor{p„) ] ^J^'''" 

A refined version of this code, one that avoids the start^ample method com- 
pletely, can be programmed. Here, we deploy the code for all sensors by sending 
methods sample and forward to all the sensors in the network by invoking deploy. 
Once deployed, the code is activated with a call to sample in the sink, instead of 
using the start^ample method as above. 

MSensor(p) = { 

deploy = (x) install x; net . deploy [x] 

} 

MSink(p) = { 

forward = (x,y) log_pos i t lo n _a n d _va I u e [x , y ] 

} 

[ net . deploy [{ 

sample = () net . sample [] ; 

install {sample = () sense (x) in net . forwa rd [ p , xj 

this . sample [] } ; 

this . sample [] 
forward = (x, y) net . forwa rd [x , y] 

}]; 

net . sample [] , MSink(p)] g'" | 
[idle, MSensor(pi)] ^^^■'•1 | ... | [idle, MSensor{p„) ] ^J^'''" 

Notice that the implementation of the method sample has changed. Here, when 

the method is executed for the first time at each sensor, it starts by propagating 
the call to its neighborhood and then, it changes itself through an install call. 
The newly installed code of sample is the same as the one in the first implemen- 
tation of the example. The method then continues to execute and calls the new 
version of sample, which starts sampling the field and forwarding values. 

1.5 Sealing sensors 

This example shows how we can install a sensor network with a module that 
contains a method, seal, that prevents any further dynamic re-programming of 
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the sensors, preventing anyone from tampering with the instaUed code. The 
module also contains a method, unseal that restores the original deploy method, 
thus allowing dynamic re-programming again. The sink just installs the module 
containning these methods in the network by broadcasting a method call to 
deploy. Each sensor that receives the call, installs the module and floods the 
neighborhood with a replica of the call. Another message by the sink then 
replaces the deploy method itself and rc-implcmcnts it to idle . This prevents 
any further instalation of software in the sensors and thus effectively seals the 
network from external interaction other than the one allowed by the remainder 
of the methods in the modules of the sensors. 

MSensor = { 

deploy = (x) install x; net . deploy [x] 



} 

MSink = { } 

[ net . deploy [{ 



seal = ( ) ' 



install {deploy 
install {deploy 



idle} 

(x) install x; net . deploy [x] } 



unseal =0 

}]; 

net . seal [] , MSink] I 
[idle , MSensor] H''^ 



p.r 



I [ idle , MSensor] 
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Abstract 

We consider the problem of providing a rigorous model for programming wireless sensor networks. 
Assuming that collisions, packet losses, and errors are dealt with at the lower layers of the protocol stack, 



, we propose a Calculus for Sensor Networks (CSN) that captures the main abstractions for programming 

. applications for this class of devices. Besides providing the syntax and semantics for the calculus, we 
show its expressiveness by providing implementations for several examples of typical operations on 

^ sensor networks. Also included is a detailed discussion of possible extensions to CSN that enable the 

. modeUng of other important features of these networks such as sensor state, sampling strategies, and 

. network security. 

^ I keywords: Sensor Networks, Ad-Hoc Networks, Ubiquitous Computing, Process-Calculi, Programming 

^ . Languages. 
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L Introduction 

A. The Sensor Network Challenge 

Sensor networks, made of tiny, low-cost devices capable of sensing the physical world and communicat- 
ing over radio links [3], are significantly different from other wireless networks: (a) the design of a sensor 
network is strongly driven by its particular application, (b) sensor nodes are highly constrained in terms of 
power consumption and computational resources (CPU, memory), and (c) large-scale sensor applications 
require self-configuration and distributed software updates without human intervention. Previous work on 
fundamental aspects of wireless sensor networks has mostly focused on communication-oriented models, 
in which the sensor nodes are assumed to store and process the data, coordinate their transmissions, 
organize the routing of messages within the network, and relay the data to a remote receiver (see e.g. [4, 
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Fig. 1. A wireless sensor network is a collection of small devices that, once deployed on a target area, organize themselves in 
an ad-hoc network, collect measurements of a physical process and transmit the data over the wireless medium to a data fusion 
center for further processing. 

14, 24] and references therein). Although some of these models provide useful insights {e.g. into the 
connectivity characteristics or the overall power efficiency of sensor networks) there is a strong need for 
formal methods that capture the inherent processing and memory constraints, and illuminate the massively 
parallel nature of the sensor nodes' in-network processing. If well adapted to the specific characteristics 
of sensor networks, a formalism of this kind, specifically a process calculus, is likely to have a strong 
impact on the design of operating systems, communication protocols, and programming languages for 
this class of distributed systems. 

In terms of hardware development, the state-of-the-art is well represented by a class of multi-purpose 
sensor nodes called wiotejQ [8], which were originally developed at UC Berkeley and are being deployed 
and tested by several research groups and start-up companies. In most of the currently available imple- 

'Xrademark of Crossbow Technology, Inc. 
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mentations, the sensor nodes are controlled by module-based operating systems such as TinyOS [1] and 
programming languages like nesC [11] or Tiny Script/Mate [17]. In our view, the programming models 
underlying most of these tools have one or more of the following drawbacks: 

1) they do not provide a rigorous model (or a calculus) of the sensor network at the programming 
level, which would allow for a formal verification of the correctness of programs, among other 
useful analysis; 

2) they do not provide a global vision of a sensor network application, as a specific distributed 
application, making it less intuitive and error prone for programmers; 

3) they require the programs to be installed on each sensor individually, something unrealistic for 
large sensor networks; 

4) they do not allow for dynamic re-programming of the network. 

Recent middleware developments such as Deluge [15] and Agilla [9] address a few of these drawbacks by 
providing higher level programming abstractions on top of TinyOS, including massive code deployment. 
Nevertheless, we are still far from a comprehensive programming solution with strong formal support 
and analytical capabilities. 

The previous observation motivates us to design a sensor network programming model from scratch. 
Beyond meeting the challenges of network-wide programming and code deployment, the model should 
be capable of producing quantitative information on the amount of resources required by sensor network 
programs and protocols, and also of providing the necessary tools to prove their correctness. 

B. Related Work 

Given the distributed and concurrent nature of sensor network operations, we build our sensor network 
calculus on thirty years of experience gathered by concurrency theorists and programming language 
designers in pursuit of an adequate formalism and theory for concurrent systems. The first steps towards 
this goal were given by Milner [20] with the development of CCS (Calculus of Communicating Systems). 
CCS describes computations in which concurrent processes may interact through simple synchronization, 
without otherwise exchanging information. Allowing processes to exchange resources (e.g., hnks, memory 
references, sockets, code), besides synchronizing, considerably increases the expressive power of the 
formal systems. Such systems, known as process-calculi, are able to model the mobiUty patterns of the 
resources and thus constitute valuable tools to reason about concurrent, distributed systems. 
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The first such system, built on Milner's work, was the vr-calculus [21]. Later developments of this initial 
proposal allowed for further simplification an provided an asynchronous form of the calculus [5, 13]. Since 
then, several calculi have been proposed to model concurrent distributed systems and for many there are 
prototype implementations of programming languages and run-time systems (e.g. Join [10], TyCO [27], 
X-Klaim [16], and Nomadic Pict [28]). 

Previous work by Prasad [23] established the first process calculus approach to modeling broadcast 
based systems. Later work by Ostrovsky, Prasad, and Taha [22] established the basis for a higher-order 
calculus for broadcasting systems. The focus of this line of work hes in the protocol layer of the networks, 
trying to establish an operational semantics and associated theory that allows assertions to be made about 
the networks. More recently, Mezzetti and Sangiorgi [19] discuss the use of process calculi to model 
wireless systems, again focusing on the details of the lower layers of the protocol stack (e.g. collision 
avoidance) and establishing an operational semantics for the networks. 

C. Our Contributions 

Our main contribution is a sensor network programming model based on a process calculus, which we 
name Calculus of Sensor Networks (CSN). Our calculus offers the following features that are specifically 
tailored for sensor networks: 

• Top-Level Approach: CSN focuses on programming and managing sensor networks and so it assumes 
that colhsions, losses, and errors have been dealt with at the lower layers of the protocol stack and 
system architecture (this distinguishes CSN from the generic wireless network calculus presented 
in [19]); 

• Scalability: CSN offers the means to provide the sensor nodes with self-update and self-configuration 
abiUties, thus meeting the challenges of programming and managing a large-scale sensor network; 

• Broadcast Communication: instead of the peer-to-peer (uiucast) commuiucation of typical process 
calculi, CSN captures the properties of broadcast communication as favored by sensor networks 
(with strong impact on their energy consumption); 

• Ad-hoc Topology: network topology is not required to be programmed in the processes, which would 
be unrealistic in the case of sensor networks; 

• Communication Constraints: due to the power hmitations of their wireless interface, the sensor nodes 
can only commuiucate with their direct neighbors in the network and thus the notion of neighborhood 
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of a sensor node, i.e. the set of sensor nodes within its communication range, is introduced directly 
in the calculus; 

• Memory and Processing Constraints: the typical limitations of sensor networks in terms of memory 
and processing capabilities are captured by explicitly modeling the internal processing (or the 
intelligence) of individual sensors; 

• Local Sensing: naturally, the sensors are only able to pick up local measurements of their environment 
and thus have geographically limited sensitivity. 

To provide these features, we devise CSN as a two-layer calculus, offering abstractions for data 
acquisition, communication, and processing. The top layer is formed by a network of sensor nodes 
immersed in a scalar or vector field (representing the physical process captured by the sensor nodes). 
The sensor nodes are assumed to be running in parallel. Each sensor node is composed of a collection 
of labeled methods, which we call a module, and that represents the code that can be executed in the 
device. A process is executed in the sensor node as a result of a remote procedure call on a module by 
some other sensor or, seen from the point of view of the callee, as a result of the reception of a message. 
Sensor nodes are multithreaded and may share state, for example, in a tuple-space. Finally, by adding 
the notions of position and range, we are able to capture the nature of broadcast communication and the 
geographical limits of the sensor network applications. 

The remainder of this paper is structured as follows. The next section describes the syntax and semantics 
of the CSN calculus. Section |lll] presents several examples of functionalities that can be implemented 
using CSN and that are commonly required in sensor networks. In Section |IV] we discuss some design 
options we made and how we can extend CSN to model other aspects of sensor networks. Finally, 
Section |V] presents some conclusions and directions for future work. 

II. The Calculus 

This section addresses the syntax and the semantics of the Calculus for Sensor Networks. For simplicity, 
in the remainder of the paper we will refer to a sensor node or a sensor device in a network as a sensor. 
The syntax is provided by the grammar in Figure |2l and the operational semantics is given by the 
reduction relation depicted in Figures [3] and ID 
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Fig. 2. The syntax of CSN. 



A. Syntax 

Let a denote a possible empty sequence ai . . . a„ of elements of the syntactic category a. Assume a 
countable set of labels, ranged over by letter I, used to name methods within modules, and a countable set 
of variables, disjoint from the set of labels and ranged over by letter x. Variables stand for communicated 
values (e.g. battery capacity, position, field measures, modules) in a given program context. 

The syntax for CNS is found in Figure [2] We explain the syntactic constructs along with their informal, 
intuitive semantics. Refer to the next section for a precise semantics of the calculus. 

Networks N denote the composition of sensor networks S with a (scalar or vector) field F. A field is 



6 



a set of pairs (position, measure) describing tlie distribution of some physical quantity {e.g. temperature, 
pressure, humidity) in space. The position is given in some coordinate system. Sensors can measure the 
intensity of the field in their respective positions. 

Sensor networks S are flat, unstructured collections of sensors combined using the parallel composition 
operator. 

A sensor [P, M]^'^ represents an abstraction of a physical sensing device and is parametric in its position 
p, describing the location of the sensor in some coordinate system; its transmission range specified by 
the radius r of a circle centered at position p; and its battery capacity b. The position of the sensors may 
vary with time if the sensor is mobile in some way. The transmission range, on the other hand, usually 
remains constant over time. A sensor with the battery exhausted is designated by off . 

Inside a sensor there exists a running program P and a module M. A module is a collection of methods 
defined as I = {x)P that the sensor makes available for internal and for external usage. A method is 
identified by label I and defined by an abstraction {x)P: a program P with parameters x. Method names 
are pairwise distinct within a module. Mutually recursive method definitions make it possible to represent 
infinite behavior. Intuitively, the collection of methods of a sensor may be interpreted as the function 
calls of some tiny operating system installed in the sensor. 

Communication in the sensor network only happens via broadcasting values from one sensor to 
its neighborhood: the sensors inside a circle centered at position p (the position of the sensor) with 
radius r. A broadcast sensor [P, M]^'^{S} stands for a sensor during the broadcast phase, having already 
communicated with sensors S. While broadcasting, it is fundamental to keep track of the sensors engaged 
in communication so far, thus preventing the delivery of the same message to the same sensor during one 
broadcasting operation. Target sensors are collected in the bag of the sensor emitting the message. Upon 
finishing the broadcast the bag is emptied out, and the (target) sensors are released into the network. This 
construct is a run-time construct and is available to the programmer. 

Programs are ranged over by P. The idle program denotes a terminated thread. Method invocation, 
selects a method v (with arguments v) either in the local module or broadcasts the request to 
the neighborhood sensors, depending whether t is the keyword this or the keyword net , respectively. 
Program sense (x) in P reads a measure from the surrounding field and binds it to x within P. Installing 
or replacing methods in the sensor's module is performed using the construct install v. The calculus also 
offers a standard form of branching through the if v then P else P construct. 

Programs P and Q may be combined in sequence, P ; Q, or in parallel, P\Q. The sequential 
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composition P ; Q designates a program that first executes P and then proceeds with the execution of 
Q. In contrast, P \ Q represents the simultaneous execution of P and Q. 

Values are the data exchanged between sensors and comprise field measures m, positions p, battery 
capacities b, and modules M. Notice that this is not a higher-order calculus: communicating a module 
means the ability to transfer its code to, to retransmit it from, or to install it in a remote sensor. 

B. Examples 

Our first example illustrates a network of sensors that sample the field and broadcast the measured 
values to a special node known as the sink. The sink node may be no different from the other sensors 
in the network, except that it usually possesses a distinct software module that allows it to collect and 
process the values broadcasted in the network. The behavior we want to program is the following. The 
sink issues a request to the network to sample the field; upon reception of the request each sensor samples 
the field at its position and broadcasts the measured value back to the sink; the sink receives and processes 
the values. An extended version of this example may be found in Section IIII-BI 

The code for the modules of the sensors, MSensor(p, r), and for the sink, MSink(p, r), is given below. 
Both modules are parametric in the position and in the broadcasting range of each sensor. 

As for the module equipping the sensors, it has a method sample that, when invoked, propagates the 
call to its neighborhood (net.sample[];), samples the field (sense x in ... ) and forwards the value to the 
network ( ... net.forward[p,x]). Notice that each sensor propagates the original request from the sink. 
This is required since in general most of the sensors in the network will be out of broadcasting range 
from the sink. Therefore each sensor echos the request, hopefully covering all the network. Message 
forwarding will be a recurrent pattern found in our examples. Another method of the sensors' module is 
forward that simply forwards the values from other sensors through the network. 

The module for the sink contains a different implementation of the forward method, since the sink will 
gather the values sent by the sensors and will log them. Here we leave unspecified the processing done 
by the log_position_and_value program. 

The network starts-up with all sensors idle, except for the sink that requests a sampling (net.sample[]). 

MSensor(p,r) = { sample = () net . sample [] ; sense x in net . forward [p , x] 

forward = (x,y) net . forward [x , y] } 
MSink(p,r) = { forward = (x,y) log_position_and_value [x ,y] } 
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[ net. sample [] ,MSink(p,r)] I'' \ 

[idle ,MSensor(pi,ri)] P^^'-M ... I [ idle , MSensor(p„,r„)] p-''" 

The next example illustrates the broadcast, the deployment, and the installation of code. The example 
runs as follows. The sink node deploys some module in the network (net.deploy[M]) and then seals the 
sensors (net. seal [] ), henceforth preventing any dynamic re-programming of the network. An extended 
version of the current example may be found in Section IIII-EI 

The code for the modules of the sensors and of the sink is given below. The module M is the one 
we wish to deploy to the network. It carries the method seal that forwards the call to the network and 
installs a new version of deploy that does nothing when executed. 

MSensor(p,r) = { deploy = (x) net . deploy [x ] ; install x } 
MSink(p, r) = {} 

M = { seal = net. seal []; install { deploy = () idle } } 

[ net . deploy [M] ; net. seal [] ,MSink(p,r)] I'' 

[idle ,MSensor(pi,ri)] P^^^-^M ... I [ idle , MSensor(p„,r„) ] f-;-'^" 



C. Semantics 

The calculus has two name bindings: field sensing and method definitions. The displayed occurrence of 
name Xi is a binding with scope P both in sense (xi, . . . , Xj, . . . , Xn) in P and in / = (xi, . . . , Xj, . . . , x„) P. 
An occurrence of a name is free if it is not in the scope of a binding. Otherwise, the occurrence of the 
name is bound. The set of free names of a sensor S is referred as fn(5). 

Following Milner [20] we present the reduction relation with the help of a structural congruence 
relation. The structural congruence relation =, depicted in Figure [3l allows for the manipulation of term 
structure, adjusting sub-terms to reduce. The relation is defined as the smallest congruence relation on 
sensors (and programs) closed under the rules given in Figure [3] 

The parallel composition operators for programs and for sensors are taken to be commutative and 
associative with idle and off as their neutral elements, respectively {vide Rules S -MONOID-PROGRAM 
and S-monoid-Sensor). Rule S-idle-seq asserts that idle is also neutral with respect to sequential 
composition of programs. Rule S-PROGRAM-STRU incorporates structural congruence for programs into 
sensors. When a sensor is broadcasting a message it uses a bag to collect the sensors as they become 
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Pi\P2 = P2\Pi, P\ idle =P, Pi I (P2 1 P3) = (Pi I P2) I P3 (S -monoid-Program) 
Si\S2 = S2\Si, 5 1 off = S, Si \ {S2 1 S3) = {Si 1 52) I ^3 (S-monoid-Sensor) 



Pi = P, 



2 



idle ; P = P ,.ip,r_rp ,.ip,r (S-IDLE-SEQ, S-PROGRAM-STRU) 



[P, MjP'"^ = [P, M]P'"{off } \p Af]g'"^-Off'^ (S -BROADCAST, S -BAT-EXHAUSTED) 



Fig. 3. Structural congruence for processes and sensors. 



engaged in communication. Rule S -BROADCAST allows for a sensor to start the broadcasting operation. 
A terminated sensor is a sensor with insufficient battery capacity for performing an internal or an external 
reduction step (vide Rule S-BAT-EXHAUSTED). 

The reduction relation on networks, notation S,F —>■ S',F, describes how sensors S can evolve 
(reduce) to sensors S", sensing the field F. The reduction is defined on top of a reduction relation for 
sensors, notation 5 — >i? 5', inductively defined by the rules in Figure ID The reduction for sensors is 
parametric on field F and on two constants Cin and Cout that represent the amount of energy consumed 
when performing internal computation steps (cin) and when broadcasting messages (Cout)- 

Computation inside sensors proceeds by invoking a method (either local — Rules R-METHOD and R- 
NO-METHOD — or remote — Rules R-BROADCAST and R-RELEASE), by sensing values (Rule R-SENSE), 
and by updating the method collection of the sensor (Rule R-INSTALL). 

The invocation of a local method /j with arguments v evolves differently depending on whether or 
not the definition for li is part of the method collection of the sensor. Rule R-METHOD describes the 
invocation of a method from module M, defined as M{li) = {xi)Pi. The result is the program Pi where 
the values v are bound to the variables in x. When the definition for li is not present in M, we have 
decided to actively wait for the definition (see Rule R-NO-METHOD). Usually invoking an undefined 
method causes a program to get stuck. Typed programming languages use a type system to ensure that 
there are no invocations to undefined methods, ruling out all other programs at compile time. At run- 
time, another possible choice would be to simply discard invocations to undefined methods. Our choice 
provides more resilient applications when coupled with the procedure for deploying code in a sensor 
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M{k) = {X,)P, b > Cin 



[this./,[^l ; Pi\P2,Mr/ [Pi[v/x,] ; A | P2 , M] ^'^^^ 
k dom(M) 

[this .k[v] ; Pi I P2, Mjl'' -^F [this .k[v] ; Pi | P2, M]^'" 



d(p,/)<r > Cout 



[net .k[v] ; Pi | P2, M]f'^{5} | [P', M']{/ ^f 

[nQ\.k[v] ■ Pi|P2,M]|:''^{5|[P'|this./,[T;],MX''"} 

[net .k[v] ■ Pi I P2,M]l''{S} ^f [Pi | P2, MJ^^^^^ | 5 

h > C|n 

[install M' ■ Pi I P2, M]^''' -^f [Pi | P2, M + M']^!"^^^ 

^ > Cin 



[sense (f) in P ; Pi | P2, M]^''^ ^f [P[P(p)/x] ; Pi | P2, M] 



p,r 
b-c-,„ 



Si 



>F J2 



S I 5*1 — >i;' 5" I 5*2 



Dl = D2 J2 J3 ^3 = ^4, 

Si — >F »S'4 

S — >F S' 



(R-method) 
(r-no-method) 
(r-broadcast) 



(R-RELEASE) 
(R-INSTALL) 

(R-SENSE) 



5, P ^ S' F 



(R-PARALLEL, R-STRUCTURAL) 



(R-NETWORK) 



Fig. 4. Reduction semantics for processes and networks. 



network. We envision that if we invoke a method in the network after some code has been deployed (see 
Example IIII-DI ). there may be some sensors where the method invocation arrives before the deployed 
code. With the semantics we propose, the call actively waits for the code to be installed. 

Sensors communicate with the network by broadcasting messages. A message consists of a remote 
method invocation on unspecified sensors in the neighborhood of the emitting sensor. In other words, 
the messages are not targeted to a particular sensor (there is no peer-to-peer communication). The 
neighborhood of a sensor is defined by its communication radius, but there is no guarantee that a message 
broadcasted by a given sensor aiTives at all surrounding sensors. There might be, for instance, landscape 
obstacles that prevent two sensors, otherwise within range, from communicating with each other. Also, 
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during a broadcast operation the message must only reach each neighborhood sensor once. Notice that we 
are not saying that the same message can not reach the same sensor multiple times. In fact it might, but as 
the result of the echoing of the message in subsequent broadcast operations. We model the broadcasting 
of messages in two stages. Rule R-BROADCAST invokes method /j in the remote sensor, provided that the 
distance between the emitting and the receiving sensors is less that the transmission radius {d{p,p') < r). 
The sensor receiving the message is put in the bag of the emitting sensor, thus preventing multiple 
deliveries of the same message while broadcasting. Observe that the rule does not enforce the interaction 
with all sensors in the neighborhood. Rule R-RELEASE finishes the broadcast by consuming the operation 
(net .li[v\), and by emptying out the contents of the emitting sensor's bag. A broadcast operation starts 
with the application of Rule S-BROADCAST, proceeds with multiple (eventually none) applications of 
Rule R-BROADCAST (one for each target sensor), and terminates with the application of Rule R-RELEASE. 

Installing module M' in a sensor with a module M, Rule R-INSTALL, amounts to add to M the methods 
in M' (absent in M), and to replace (in M) the methods common to both M and M'. Rigorously, the 
operation of installing module M' on top of M, denoted M + M', may be defined as M + M' = 
(M \ M') U M'. The + operator is reminiscent of Abadi and Cardelli's operator for updating methods 
in their imperative object calculus [2]. 

A sensor senses the field in which it is immersed. Rule R-SENSE, by sampling the value of the field 
F in its position p and, continues the computation replacing this value for the bound variables x in 
program P. 

Rule R-PARALLEL allows reduction to happen in networks of sensors and Rule R-STRUCTURAL brings 
structural congruence into the reduction relation. 

D. The Operational Semantics Illustrated 

To illustrate the operational semantics of CNS, we present the reduction steps for the examples 
discussed at the end of Section III-BI During reduction we suppress the side annotations when writing 
the sensors. Due to space constraints we consider a rather simple network with just the sink and another 
sensor. 

[ net . sample [], MSink (p ,r )] | [ idle , MSensor(pi,ri) ] 

We assume that the sensor is within range from the sink and vice-versa. This network may reduce as 
follows: 
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[net.sample[],MSink(p,r)] | [idle,MSensor(pi,ri)] = 
[net.sample[],MSink(p,r)]{off} | [idle,MSensor(pi,ri)] 



(S-BROADCAST) 



(d(p,pi) < r, R-BROADCAST, S-MONOID-SENSOR) 

[net.sample[],MSink(p,r)] {[this.sample[] || idle,MSensor(pi,ri)]} ^= 

(R-release, S-monoid-Program) 



[idle,MSink(p,r) 
[idle,MSink(p,r) 
[idle,MSink(p,r) 
[idle,MSink(p,r) 
[idle,MSink(p,r) 



[this.sample[],MSensor(pi,ri)] (R-method) 

[net.sample[]; sense x in net.forward[pi,x],MSensor(pi,ri)] = (S-broadcast) 

[net.sample[]; sense x in net.forward[pi,x],MSensor(pi,ri)]{off} (R-release) 

[sense x in net.forward[pi,x],MSensor(pi,ri)] (R-sense) 
[net.forward[pi,i^(pi)], MSensor(pi,ri)] = (S-monoid-Sensor) 

[net.forward[pi,F(pi)], MSensor(pi,ri)] | [idle,MSink(p,r)] = (S-broadcast) 
[net.forward[pi,F(pi)], MSensor(pi,ri)]{off} | [idle,MSink(p,r)] —>■= 

(d(pi,p) < ri, R-BROADCAST, S-MONOID-SENSOR) 

[net.forward[pi,f (pi)], MSensor(pi,ri)]{[this.forward[pi,i^(pi)] I| idle, MSink(p,r)]} —^= 

(R-RELEASE, S-MONOID-PROGRAM) 



[idle, MSensor(pi,ri)] | [this.forward[pi,F(pi)], MSink(p,r)] 

[idle, MSensor(pi,ri)] | [log_position_and_value[pi,-F(pi)], MSink(p,r)] ■ 

[log_position_and_value[pi,F(pi)] | [idle, MSensor(pi,ri)], MSink(p,r)] 



(R-METHOD) 

(S-monoid-Sensor) 



So, after these reduction steps the sink gets the field values from the sensor at position pi and logs them. 
The sensor at pi is idle waiting for further interaction. 

Following we present the reduction step for our second (and last) example of Section III-BI where we 
illustrate the broadcast, the deployment, and the installation of code. Again, due to space restrictions, we 
use a very simple network with just the sink and another sensor, both within reach of each other. 
[ net . deploy [M] ; net . seal [], MSink(p , r ) ] | [ idle , MSensor(pi,ri)] 
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This network may reduce as follows: 

[net.deploy[M]; net.seal [], MSink(p,r)] | [idle,MSensor(pi,ri)] = (S-broadcast) 
[net.deploy[M]; net.seal [], MSink(p,r)]{off} | [idle,MSensor(pi,ri)] ^= 

(d{p,pi) < r, R-BROADCAST, S-MONOID-SENSOR) 

[net.deploy[M]; net.seal [], MSink(p,r)] | {[this.deploy[M] || idle, MSensor(pi,ri)]} ^= 

(R-release, S-monoid-Program) 

[net. seal [], MSink(p,r)] | [this.deploy[M], MSensor(pi,ri)] ^ (R-method) 

[net.seal [], MSink(p,r)] | [net.deploy[M]; install M, MSensor(pi,ri)] = (S-broadcast) 

[net. seal [], MSink(p,r)] | [net.deploy[M]; install M, MSensor(pi,ri)]{off} 

(R-RELEASE, S-MONOID-SENSOR) 

[net.seal [], MSink(p,r)] | [install M, MSensor(pi,ri)] ^ (R-install) 

[net.seal [], MSink(p,r)] | [idle, MSensor(pi,ri)+M] = (S-broadcast) 

[net.seal [], MSink(p,r)]{off} | [idle, MSensor(pi,ri)+M] ^= 

(d{p,pi) < r, R-broadcast, S-monoid-Sensor) 

[net.seal [], MSink(p,r)] {[this. seal [] || idle, MSensor(pi,ri)+M]} — >= 

(R-RELEASE, S-MONOID-PROGRAM) 



[idle,MSink(p,r)] 
[idle,MSink(p,r)] 
[idle,MSink(p,r)] 

[idle,MSink(p,r)] 
[idle,MSink(p,r)] 



[this. seal [], MSensor(pi,ri)+M] -> (R-method) 
[net.seal []; install {deploy = () idle}, MSensor(pi,ri)+M] = (S-broadcast) 
[net.seal []; install {deploy = () idle}, MSensor(pi,ri)+M]{off} ^= 

(R-RELEASE, S-MONOID-SENSOR) 

[install {deploy =0 idle}, MSensor(pi,ri)+M] ^ (R-install) 
[idle, MSensor(pi,ri)+M+{deploy = () idle}] 



After these reductions, the sink is idle after deploying the code to the sensor at p. The sensor at p 
is also idle, waiting for interaction, but with the code for the module M installed and with the deploy 
method disabled. 
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III. Programming Examples 

In this section we present some examples, programmed in CSN, of typical operations performed on 
networks of sensors. Our goal is to show the expressiveness of the CSN calculus just presented and 
also to identify some other aspects of these networks that may be interesting to model. In the following 
examples, we denote as MSensor and MSink the modules installed in any of the anonymous sensors in 
the network and the modules installed in the sink, respectively. Note also that all sensors are assumed to 
have a builtin method, deploy, that is responsible for installing new modules. The intuition is that this 
method is part of the tiny operating system that allows sensors to react when first placed in the field. 
Finally, we assume in these small examples that the network layer supports scoped flooding. We shall 
see in the next section that this can be supported via software with the inclusion of state in sensors. 

A. Ping 

We start with a very simple ping program. Each sensor has a ping method that when invoked calls 
a method forward in the network with its position and battery charge as arguments. When the method 
forward is invoked by a sensor in the network, it just triggers another call to forward in the network. 

The sink has a distinct implementation of this method. Any incomming invocation logs the position and 
battery values given as arguments. So, the overall result of the call net. ping [] in the sink is that all 
reachable sensors in the network will, in principle, receive this call and will flood the network with their 
positions and battery charge values. These values eventually reach the sink and get logged. 

MSensor (p,b) = { 

ping = net . forward [p, b] ; net.ping[] 

forward = (x,y) net . forward [x , y] 

} 

MSink(p,b) = { 

forward = (x,y) log_position_and_power [x , y ] 

} 

[net. ping [] , MSink(p,6)] | 

[idle, MSensor | ... | [idle, MSensor (/;„,/;„)] j;,"'''" 
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B. Querying 

This example shows how we can program a network with a sink that periodically queries the network 
for the readings of the sensors. Each sensor has a sample method that samples the field using the sense 
construct and calls the method forward in the neighbourhood with its position and the value sampled as 
arguments. The call then queries the neighbourhood recursively with a replica of the original call. The 
original call is, of course, made from the sink, which has a method start_sample that calls the method 
sample in the network within a cycle. Note that, if the sink had a method named sample instead of 
start_sample, it might get a call to sample from elsewhere in the network that could interfere with the 
sampling control cycle. 

MSensor(p) = { 

sample = () sense (x) in net. forward [p, x]; net.sample[] 

forward = (x, y) net . forward [x , y] 

} 

MSink(p) = { 

start_sample = () net . sample [] ; this . start_sample [] 
forward = (x, y) log_position_and_value [x , y ] 

} 



[thiis . start. sample [] , MSink(p)] 'p-'' 



b 



[idie, U^ensor (pi)] ll'""^ \ ... | [idie, MSensor(p„) ] ^ 



C. Polling 

In this example the cycle of the samphng is done in each sensor, instead of in the sink, as in the 
previous example. The sink just invokes the method start_sample once. This method propagates the call 
through the network and invokes sample, for each sensor. This method samples the field, within a cycle, 
and forwards the result to the network. This implementation requires less broadcasts than the previous 
one as the sink only has to call start_sample on the network once. On the other hand, it increases the 
amount of processing per sensor. 

MSensor(p) = { 

start_sample = () net . start.sample [ ] ; thi is . sample [ ] 

sample = () sense (x) in net . forward [p , x]; tliis . sample [] 

forward = (x, y) net . forward [x , y] 
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} 

MSink(p) = { 

forward = (x, y) log_position_and_value [x , y] 

} 

[ net . start_example [] , MSink(p)] l'' \ 

[idle, MSensor(pi)] ^^'"^ I ■■■ I [idle, MSensor(p„) ] p-'^" 



D. Code deployment 

The above examples assume we have some means of deploying the code to the sensors. In this example 
we address this problem and show how it can be programmed in CSN. The code we wish to deploy 
and execute is the same as the one in the previous example. To achieve this goal, the sink first calls 
the deploy method on the network to install the new module with the methods start_sample, sample and 
forward as above. This call recursively deploys the code to the sensors in the network. The sink then calls 
start_sample to start the sampling, again as above, and waits for the forwarded results on the method 
forward. 

MSensor(p) = { 

deploy = (x) install x; net . deploy [x] 

} 

MSink(p) = { 

forward = (x,y) log_position_and_value [x , y ] 

} 

[net.deploy[{ 

start_sample = () net . start.sample [] ; this . sample [] 

sample = () sense (x) in net. forward [p, x]; this . sample [] 

forward = (x, y) net . forward [x , y] 

}]; 



net . start-sample [] , MSink(p)] ^' 



[idle , MSensor(pi)] ^ 



pi,ri 



[idle , MSensor(p„)] 



A refined version of this code, one that avoids the start_sample method completely, can be programmed. 
Here, we deploy the code for all sensors by sending methods sample and forward to all the sensors in 
the network by invoking deploy. Once deployed, the code is activated with a call to sample in the sink, 
instead of using the start_sample method as above. 
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MSensor(p) 
deploy 



{ 



= (X) 



install x; net . deploy [x] 



} 

MSink(p) 



{ 



forward 



= (x,y) log_position_and_value [x , y] 



} 

[net.deploy[{ 
sample 



= net. sample [] ; 

install {sample = () sense (x) in net. forward [p, x]; 

this . sample [] } ; 

this . sample [] 
= (x, y) net . forward [x , y] 



forward 



}]; 

net. sample [] , MSink(p)] I''' \ 
[idle , MSensor(pi)] ^^^-^ | ... 



[ idle , MSensor(p„)] ^; 



Notice that the implementation of the method sample has changed. Here, when the method is executed 
for the first time at each sensor, it starts by propagating the call to its neighborhood and then, it changes 
itself through an install call. The newly installed code of sample is the same as the one in the first 
implementation of the example. The method then continues to execute and calls the new version of 
sample, which starts sampling the field and forwarding values. 

E. Sealing sensors 

This example shows how we can install a sensor network with a module that contains a method, seal, 
that prevents any further dynamic re-programming of the sensors, preventing anyone from tampering 
with the installed code. The module also contains a method, unseal that restores the original deploy 
method, thus allowing dynamic re-programming again. The sink just installs the module containning 
these methods in the network by broadcasting a method call to deploy. Each sensor that receives the call, 
installs the module and floods the neighborhood with a replica of the call. Another message by the sink 
then replaces the deploy method itself and re-implements it to idle . This prevents any further instalation 
of software in the sensors and thus effectively seals the network from external interaction other than the 
one allowed by the remainder of the methods in the modules of the sensors. 



18 



MSensor = { 

deploy = (x) install x; net . deploy [x] 

} 

MSink = { } 
[net. deploy[{ 

seal = install {deploy = () idle} 

unseal = () install {deploy = (x) install x; net . deploy [x]} 

}]; 

net. seal [] , MSink] | 

[idle, MSensor] ^^^■'^1 I ■■■ I [idle, MSensor]^;;'''" 



IV. Discussion 

In the previous sections, we focused our attention on the programming issues of a sensor network 
and presented a core calculus that is expressive enough to model fundamental operations such as local 
broadcast of messages, local sensing of the environment, and software module updates. CSN allows the 
global modeling of sensor networks in the sense that it allows us to design and implement sensor network 
applications as large-scale distributed applications, rather than giving the programmer a sensor-by-sensor 
view of the programming task. It also provides the tools to manage running sensor networks, namely 
through the use of the software deployment capabilities. 

There are other important features of sensor networks that we consciously left out of CSN. In the 
sequel we discuss some of these features and sketch some ideas of how we would include support for 
them. 

a) State: From a programming point of view, adding state to sensors is essential. Sensors have some 
Hmited computational capabilities and may perform some data processing before sending it to the sink. 
This processing assumes that the sensor is capable of buffering data and thus maintain some state. In a 
way, CSN sensors have state. Indeed, the atributes p, h, and r may be viewed as sensor state. Since these 
are characteristic of each sensor and are usually controlled at the hardware level, we chose to represent 
this state as parameters of the sensors. The programmer may read these values at any time through builtin 
method calls but any change to this data is performed transparently for the programmer by the hardware 
or operating system. As we mentioned before, it is clear that the value of h changes with time. The 
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position p may also change with time if we envision our sensors endowed with some form of mobility 
{e.g., sensors dropped in the atmosphere or flowing in the ocean). 

To allow for a more systematic extension of our sensors with state variables we can assume that each 
sensor has a heap H where the values of these variables are stored: [H,P,M]^'"^ . The model chosen 
for this heap is orthogonal to our sensor calculus and for this discussion we assume that we enrich the 
values V of the language with a set of keys, ranged over by k. Our heap may thus be defined as a map H 
from keys into values. Intuitively, we can think of it as an associative memory with the usual built-in 
operations put, get, lookup, and hash. Programs running in the sensors may share state by exchanging 
keys. We assume also that these operations are atomic and thus no race conditions can arise. 

With this basic model for a heap we can re-implement the Ping example from Section IIII-AI with 
scoped flooding thus eliminating echos by software. We do this by associating a unique key to each 
remote procedure call broadcast to the network. This key is created through the built-in hash function 
that takes as arguments the position p and the battery b of the sensor. Each sensor, after receiving a call 
to ping, propagates the call to its neighborhood and generates a new key to send, with its position and 
battery charge, in a forward call. Then, it stores the key in its heap to avoid forwarding its own forward 
call. On the other hand, each time a sensor receives a call to forward, it checks whether it has the key 
associated to the call in its heap. If so, it does nothing. If not, it forwards the call and stores the key in 
the heap, to avoid future re-transmission. 

MSensor(p, b) = { 

ping = net . ping [] ; 

let k = hash[p,b] in net . forward [p , b, k]; 
put[k,.] 

forward = (x, y, k) if (!lookup[k]) then 

net . forward [x , y, k]; 
put[k,_] 

} 

MSink(p, b) = {...} 
[net. ping [] , MSink] \ 

[idle, MSensor(pi,6i)] P^'""^ | ... | [idle, MSensor(p„,6„)] 

b) Events: Another characteristic of sensors is their modus operandi. Some sensors sample the field 
as a result of instructions implemented in the software that controls them. Such is the case with CSN 
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sensors. The programmer is responsible for controlling the sensing activity of the sensor network. It is 
of course possible for sensor nodes to be activated in different ways. For example, some may have their 
sensing routines implemented at hardware or operating system level and thus not directly controllable 
by the programmer. Such classes of sensor nodes tipically sample the field periodically and are activated 
when a given condition arises {e.g., a temperature above or below a given threshold, the detection of 
CO2 above a given threshold, the detection of a strong source of infrared light). The way in which 
certain environmental conditions or events can activate the sensor is by triggering the execution of a 
handler procedure that processes the event. Support for this kind of event-driven sensors in CSN could 
be achieved by assuming that each sensor has a builtin handler procedure, say handle, for such events. 
The handler procedure, when activated, receives the value of the field that triggered the event. Note that, 
from the point of view of the sensor, the occurrence of such an event is equivalent to the deployment 
of a method invocation this.handle[v] in its processing core, where v is the field value associated with 
the event. The sensor has no control over this deployment, but may be programmed to react in different 
ways to these calls, by providing adequate implementations of the handle routine. The events could be 
included in the semantics given in Section III-CI with the following rule: 

[P, M]f [this .handle [F{p)] \ P, M]^''' (R-event) 

As in the case of the builtin method for code deployment, the handler could be programmed to change 
the behavior of the network in the presence of events. One could envision the default handler as 
handle = (x) idle, which ignores all events. Then, we could change this default behavior so that an event 
triggers an alarm that gets sent to the sink. A possible implementation of such a dynamic re-programming 
of the network default handlers can be seen in the code below. 

MSensor(p) = { handle = (x) idle } 
MSink(p) = { handle = (x) idle } 
[ net . deploy [{ 

handle = (x) net . alarm [p, x] 

alarm = (x,y) net . alarm [x , y] 

}]; 

install {alarm = (x,y) s i ng _be 1 1 [x , y ] } , 
MSink(p)] r I 

[idle, MSensor(pi)] P^^'''^ | ... | [idle, MSensortp,,)] I"/" 
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where the default implementation of the handle procedure is superseded by one that eventualy triggers 
an alarm in the sink. 

More complex behavior could be modeled for sensors that take multiple readings, with a handler 
associated with each event. 

c) Security: Finally, another issue that is of outmost importance in the management of sensor 
networks is security. It is important to note that many potential appUcations of sensor networks are in 
high risk situations. Examples may be the moiutorization of ecological disaster areas, volcanic or sismic 
activity, and radiation levels in contaminated areas. Secure access to data is fundamental to estabhsh its 
credibility and for correctly assessing risks in the management of such episodes. In CSN we have not 
taken security issues into consideration. This was not our goal at this time. However, one feature of the 
calculus may provide interesting solutions for the future. In fact, in CSN, all computation within a sensor 
results from an invocation of methods in the modules of a sensor, either originating in the network or 
from within the sensor. In a sense the modules M of the sensor work as a firewall that can be used to 
control incomming messages and implement security protocols. Thus, all remote method invocations and 
software updates might first be validated locally with methods of the sensor's modules and only then the 
actions would be performed. The idea of equipping sensors, or in general domains, with some kind of 
membrane that filters all the interactions with the surrounding network has been explored, for instance, 
in [6], in the M-calculus [25], in the Kell calculus [26], in the Brane calculi [7], in Miko [18], and 
in [12]. One possible development is to incorporate some features of the membrane model into CSN. The 
current formulation of the calculus also assumes that all methods in the module M of a sensor [P, M]^''^ 
are visible from the network. It is possible to implement an access policy to methods in such a way that 
some methods are private to the sensor, i.e., can only be invoked from within the sensor. This allows, 
for example, the complete encapsulation of the state of the sensor. 

V. Conclusions and Future Work 

Aiming at providing large-scale sensor networks with a rigorous and adequate programming model 
(upon which operating systems and high-level programming languages can be built), we presented CSN 
— a Calculus for Sensor Networks, developed specifically for this class of distributed systems. 

After identifying the necessary sensing, processing, and wireless broadcasting features of the calculus, 
we opted to base our work on a top-layer abstraction of physical and link layer communication issues 
(in contrast with previous work on wireless network calcuh [19,23]), thus focusing on the system 
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requirements for programming network-wide applications. This approach resulted in the CSN syntax and 
semantics, whose expressiveness we illustrated through a series of implementations of typical operations 
in sensor networks. Also included was a detailed discussion of possible extensions to CSN to account 
for other important properties of sensors such as state, sampling strategies, and security. 

As part of our ongoing efforts, we are currently using CSN to establish a mathematical framework for 
reasoning about sensor networks. One major objective of this work consists in providing formal proofs 
of correctness for data gathering protocols that are commonly used in current sensor networks and whose 
performance and reliability has so far only been evaluated through computer simulations and ad-hoc 
experiments. 

From a more practical point of view, the focus will be set on the development of a prototype 
implementation of CSN. This prototype will be used to emulate the behavior of sensor networks by 
software and, ultimately, to port the programming model to a natural development architecture for sensor 
network applications. 
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Abstract 

We consider the problem of providing a rigorous model for programming wireless sensor networks. 
Assuming that collisions, packet losses, and errors are dealt with at the lower layers of the protocol stack, 
, we propose a Calculus for Sensor Networks (CSN) that captures the main abstractions for programming 

■ applications for this class of devices. Besides providing the syntax and semantics for the calculus, we 
show its expressiveness by providing implementations for several examples of typical operations on 

^ ^ sensor networks. Also included is a detailed discussion of possible extensions to CSN that enable the 

. modehng of other important features of these networks such as sensor state, sampling strategies, and 

■ network security. 
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L Introduction 



^ ■ A. The Sensor Network Challenge 



Sensor networks, made of tiny, low-cost devices capable of sensing the physical world and communicat- 
ing over radio links [?], are significantly different from other wireless networks: (a) the design of a sensor 
network is strongly driven by its particular application, (b) sensor nodes are highly constrained in terms of 
power consumption and computational resources (CPU, memory), and (c) large-scale sensor applications 
require self-configuration and distributed software updates without human intervention. Previous work on 
fundamental aspects of wireless sensor networks has mostly focused on communication-oriented models, 
in which the sensor nodes are assumed to store and process the data, coordinate their transmissions, 
organize the routing of messages within the network, and relay the data to a remote receiver (see 
e.g. [?, ?, ?] and references therein). Although some of these models provide useful insights {e.g. into the 
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Fig. 1. A wireless sensor network is a collection of small devices that, once deployed on a target area, organize themselves in 
an ad-hoc network, collect measurements of a physical process and transmit the data over the wireless medium to a data fusion 
center for further processing. 

connectivity characteristics or the overall power efficiency of sensor networks) there is a strong need for 
formal methods that capture the inherent processing and memory constraints, and illuminate the massively 
parallel nature of the sensor nodes' in-network processing. If well adapted to the specific characteristics 
of sensor networks, a formalism of this kind, specifically a process calculus, is likely to have a strong 
impact on the design of operating systems, communication protocols, and programming languages for 
this class of distributed systems. 

In terms of hardware development, the state-of-the-art is well represented by a class of multi-purpose 
sensor nodes called mote^^ [?], which were originally developed at UC Berkeley and are being deployed 
and tested by several research groups and start-up companies. In most of the currently available im- 
plementations, the sensor nodes are controlled by module-based operating systems such as TinyOS [?] 
and programming languages like nesC [?] or TinyScript/Mate [?]. In our view, the programming models 

'Trademark of Crossbow Technology, Inc. 
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underlying most of these tools have one or more of the following drawbacks: 

1) they do not provide a rigorous model (or a calculus) of the sensor network at the programming 
level, which would allow for a formal verification of the correctness of programs, among other 
useful analysis; 

2) they do not provide a global vision of a sensor network application, as a specific distributed 
application, making it less intuitive and error prone for programmers; 

3) they require the programs to be installed on each sensor individually, something unrealistic for 
large sensor networks; 

4) they do not allow for dynamic re-programming of the network. 

Recent middleware developments such as Deluge [?] and Agilla [?] address a few of these drawbacks by 
providing higher level programming abstractions on top of TinyOS, including massive code deployment. 
Nevertheless, we are still far from a comprehensive programming solution with strong formal support 
and analytical capabilities. 

The previous observation motivates us to design a sensor network programming model from scratch. 
Beyond meeting the challenges of network-wide programming and code deployment, the model should 
be capable of producing quantitative information on the amount of resources required by sensor network 
programs and protocols, and also of providing the necessary tools to prove their correctness. 

B. Related Work 

Given the distributed and concurrent nature of sensor network operations, we build our sensor network 
calculus on thirty years of experience gathered by concurrency theorists and programming language 
designers in pursuit of an adequate formalism and theory for concurrent systems. The first steps towards 
this goal were given by Milner [?] with the development of CCS (Calculus of Communicating Systems). 
CCS describes computations in which concurrent processes may interact through simple synchronization, 
without otherwise exchanging information. Allowing processes to exchange resources {e.g., links, memory 
references, sockets, code), besides synchronizing, considerably increases the expressive power of the 
formal systems. Such systems, known as process-calculi, are able to model the mobility patterns of the 
resources and thus constitute valuable tools to reason about concurrent, distributed systems. 

The first such system, built on Milner's work, was the 7r-calculus [?]. Later developments of this initial 
proposal allowed for further simpUfication an provided an asynchronous form of the calculus [?, ?]. Since 
then, several calculi have been proposed to model concurrent distributed systems and for many there are 
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prototype implementations of programming languages and run-time systems (e.g. Join [?], TyCO [?], 
X-Klaim [?], and Nomadic Pict [?]). 

Previous work by Prasad [?] established the first process calculus approach to modehng broadcast based 
systems. Later work by Ostrovsky, Prasad, and Taha [?] established the basis for a higher-order calculus 
for broadcasting systems. The focus of this fine of work hes in the protocol layer of the networks, trying 
to establish an operational semantics and associated theory that allows assertions to be made about the 
networks. More recently, Mezzetti and Sangiorgi [?] discuss the use of process calcuh to model wireless 
systems, again focusing on the details of the lower layers of the protocol stack (e.g. colhsion avoidance) 
and estabhshing an operational semantics for the networks. 

C. Our Contributions 

Our main contribution is a sensor network programming model based on a process calculus, which we 
name Calculus of Sensor Networks (CSN). Our calculus offers the following features that are specifically 
tailored for sensor networks: 

• Top-Level Approach: CSN focuses on programming and managing sensor networks and so it assumes 
that colhsions, losses, and errors have been dealt with at the lower layers of the protocol stack and 
system architecture (this distinguishes CSN from the generic wireless network calculus presented 
in [?]); 

• Scalability: CSN offers the means to provide the sensor nodes with self-update and self-configuration 
abilities, thus meeting the challenges of programming and managing a large-scale sensor network; 

• Broadcast Communication: instead of the peer-to-peer (unicast) communication of typical process 
calcuh, CSN captures the properties of broadcast communication as favored by sensor networks 
(with strong impact on their energy consumption); 

• Ad-hoc Topology: network topology is not required to be programmed in the processes, which would 
be unrealistic in the case of sensor networks; 

• Communication Constraints: due to the power hmitations of their wireless interface, the sensor nodes 
can only communicate with their direct neighbors in the network and thus the notion of neighborhood 
of a sensor node, i.e. the set of sensor nodes within its communication range, is introduced directly 
in the calculus; 

• Memory and Processing Constraints: the typical hmitations of sensor networks in terms of memory 
and processing capabilities are captured by exphcitly modeling the internal processing (or the 
intelligence) of individual sensors; 
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• Local Sensing: naturally, the sensors are only able to pick up local measurements of their environment 
and thus have geographically limited sensitivity. 

To provide these features, we devise CSN as a two-layer calculus, offering abstractions for data 
acquisition, communication, and processing. The top layer is formed by a network of sensor nodes 
immersed in a scalar or vector field (representing the physical process captured by the sensor nodes). 
The sensor nodes are assumed to be running in parallel. Each sensor node is composed of a collection 
of labeled methods, which we call a module, and that represents the code that can be executed in the 
device. A process is executed in the sensor node as a result of a remote procedure call on a module by 
some other sensor or, seen from the point of view of the callee, as a result of the reception of a message. 
Sensor nodes are multithreaded and may share state, for example, in a tuple-space. Finally, by adding 
the notions of position and range, we are able to capture the nature of broadcast communication and the 
geographical limits of the sensor network applications. 

The remainder of this paper is structured as follows. The next section describes the syntax and semantics 
of the CSN calculus. Section |lll] presents several examples of functionaUties that can be implemented 
using CSN and that are commonly required in sensor networks. In Section |IV] we discuss some design 
options we made and how we can extend CSN to model other aspects of sensor networks. Finally, 
Section |V] presents some conclusions and directions for future work. 

II. The Calculus 

This section addresses the syntax and the semantics of the Calculus for Sensor Networks. For simplicity, 
in the remainder of the paper we will refer to a sensor node or a sensor device in a network as a sensor. 
The syntax is provided by the grammar in Figure |2l and the operational semantics is given by the 
reduction relation depicted in Figures [3] and ID 

A. Syntax 

Let a denote a possible empty sequence ai . . . a„ of elements of the syntactic category a. Assume a 
countable set of labels, ranged over by letter I, used to name methods within modules, and a countable set 
of variables, disjoint from the set of labels and ranged over by letter x. Variables stand for communicated 
values {e.g. battery capacity, position, field measures, modules) in a given program context. 

The syntax for CNS is found in Figure |2] We explain the syntactic constructs along with their informal, 
intuitive semantics. Refer to the next section for a precise semantics of the calculus. 
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::= 


Network 


P ::= 


Programs 




S,F 


sensors and field 


idle 


idle 








1 P\P 


parallel composition 


S 


•= 


Sensors 


1 P; P 


sequential composition 




off 


termination 


1 t.v[v] 


method invocation 




1 N\N 


composition 


\ install V 


module update 




1 i-P^^Jb 


sensor 


1 sense (x) in P 


held sensmg 






broadcast sensor 


\ if V then P else P 


conditional execution 


M 


::= 


Modules 


V :.= 


Values 




{k = {xi)Pi}iei 


method collection 


X 


variable 








1 m 


field measure 


t : 




Targets 


1 P 


position 




net 


broadcast 


1 b 


battery capacity 




1 this 


local 


1 M 


module 


Fig. 2. 


The syntax of CSN. 









Networks N denote the composition of sensor networks S with a (scalar or vector) field F. A field is 
a set of pairs (position, measure) describing the distribution of some physical quantity (e.g. temperature, 
pressure, humidity) in space. The position is given in some coordinate system. Sensors can measure the 
intensity of the field in their respective positions. 

Sensor networks S are flat, unstructured collections of sensors combined using the parallel composition 
operator. 

A sensor [P, M]^'^ represents an abstraction of a physical sensing device and is parametric in its position 
p, describing the location of the sensor in some coordinate system; its transmission range specified by 
the radius r of a circle centered at position p; and its battery capacity b. The position of the sensors may 
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vary with time if the sensor is mobile in some way. The transmission range, on the other hand, usually 
remains constant over time. A sensor with the battery exhausted is designated by off . 

Inside a sensor there exists a miming program P and a module M. A module is a collection of methods 
defined as I = {x)P that the sensor makes available for internal and for external usage. A method is 
identified by label I and defined by an abstraction {x)P: a program P with parameters x. Method names 
are pairwise distinct within a module. Mutually recursive method definitions make it possible to represent 
infinite behavior. Intuitively, the collection of methods of a sensor may be interpreted as the function 
calls of some tiny operating system installed in the sensor. 

Communication in the sensor network only happens via broadcasting values from one sensor to 
its neighborhood: the sensors inside a circle centered at position p (the position of the sensor) with 
radius r. A broadcast sensor [P, M]^f^'^ {S} stands for a sensor during the broadcast phase, having already 
communicated with sensors S. While broadcasting, it is fundamental to keep track of the sensors engaged 
in communication so far, thus preventing the delivery of the same message to the same sensor during one 
broadcasting operation. Target sensors are collected in the bag of the sensor emitting the message. Upon 
finishing the broadcast the bag is emptied out, and the (target) sensors are released into the network. This 
construct is a run-time construct and is available to the programmer. 

Programs are ranged over by P. The idle program denotes a terminated thread. Method invocation, 
t.v[v\, selects a method v (with arguments v) either in the local module or broadcasts the request to 
the neighborhood sensors, depending whether t is the keyword this or the keyword net, respectively. 
Program sense (x) in P reads a measure from the surrounding field and binds it to x within P. Installing 
or replacing methods in the sensor's module is performed using the construct install v. The calculus also 
offers a standard form of branching through the if v then P else P construct. 

Programs P and Q may be combined in sequence, P ; Q, or in parallel, P\Q. The sequential 
composition P ; Q designates a program that first executes P and then proceeds with the execution of 
Q. In contrast, P | Q represents the simultaneous execution of P and Q. 

Values are the data exchanged between sensors and comprise field measures m, positions p, battery 
capacities h, and modules M. Notice that this is not a higher-order calculus: communicating a module 
means the ability to transfer its code to, to retransmit it from, or to install it in a remote sensor. 

B. Examples 

Our first example illustrates a network of sensors that sample the field and broadcast the measured 
values to a special node known as the sink. The sink node may be no different from the other sensors 
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in the network, except that it usually possesses a distinct software module that allows it to collect and 
process the values broadcasted in the network. The behavior we want to program is the following. The 
sink issues a request to the network to sample the field; upon reception of the request each sensor samples 
the field at its position and broadcasts the measured value back to the sink; the sink receives and processes 
the values. An extended version of this example may be found in Section IIII-BI 

The code for the modules of the sensors, MSensor(p, r), and for the sink, MSink(p, r), is given below. 
Both modules are parametric in the position and in the broadcasting range of each sensor. 

As for the module equipping the sensors, it has a method sample that, when invoked, propagates the 
call to its neighborhood (net.sample[];), samples the field (sense x in ... ) and forwards the value to the 
network ( ... net.forward[p,x]). Notice that each sensor propagates the original request from the sink. 
This is required since in general most of the sensors in the network will be out of broadcasting range 
from the sink. Therefore each sensor echos the request, hopefully covering all the network. Message 
forwarding will be a recurrent pattern found in our examples. Another method of the sensors' module is 
forward that simply forwards the values from other sensors through the network. 

The module for the sink contains a different implementation of the forward method, since the sink will 
gather the values sent by the sensors and will log them. Here we leave unspecified the processing done 
by the log_position_and_value program. 

The network starts-up with all sensors idle, except for the sink that requests a sampling (net.sample[]). 

MSensor(p,r) = { sample = () net . sample [] ; sense x in net . forward [p , x] 

forward = (x,y) net . forward [x , y] } 
MSink(p,r) = { forward = (x,y) log_position_and_value [x ,y] } 

[ net . sample [] ,MSink(p,r)] l'' \ 

[idle ,MSensor(pi,ri)] P^^-^M ■■■ I [ idle , MSensor(p„,r„)] i;:^"" 

The next example illustrates the broadcast, the deployment, and the installation of code. The example 
runs as follows. The sink node deploys some module in the network (net.deploy[M]) and then seals the 
sensors (net. seal [] ), henceforth preventing any dynamic re-programming of the network. An extended 
version of the current example may be found in Section IIII-EI 

The code for the modules of the sensors and of the sink is given below. The module M is the one 
we wish to deploy to the network. It carries the method seal that forwards the call to the network and 
installs a new version of deploy that does nothing when executed. 
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Pi\P2 = P2\Pi, P\ idle =P, Pi I (P2 1 P3) = (Pi I P2) I P3 (S -monoid-Program) 

Si\S2 = S2\Si, 5 1 off = 5, Si \ {S2 1 53) = {Si 1 52) I ^3 (S-monoid-Sensor) 

P — P 

idle ; P = P rp ,^ip,rlrp ,.ip,r (S-IDLE-SEQ, S-PROGRAM-STRU) 

[P, M]^;'" = [P, M]P'"{off } \p Af]g'"^-Off'^ (S -BROADCAST, S -BAT-EXHAUSTED) 

Fig. 3. Structural congruence for processes and sensors. 



MSensor(p,r) = { deploy = (x) net . deploy [x ] ; install x } 
MSink(p, r) = {} 

M = { seal = net. seal []; install { deploy = () idle } } 

[net. deploy [M]; net. seal [] ,MSink(p,r)] f'' 

[idle ,MSensor(pi,ri)] ^^^'''M ... | [ idle , MSensor(p„,r„)] f^''" 



C. Semantics 

The calculus has two name bindings: field sensing and method definitions. The displayed occurrence of 
name x-i is a binding with scope P both in sense {xi, . . . , Xj, . . . , Xn) in P and in / = (xi, . . . , Xj, . . . , x„) P. 
An occurrence of a name is free if it is not in the scope of a binding. Otherwise, the occurrence of the 
name is bound. The set of free names of a sensor S is referred as fn(5). 

Following Milner [?] we present the reduction relation with the help of a structural congruence relation. 
The structural congruence relation =, depicted in Figure |3l allows for the manipulation of term structure, 
adjusting sub-terms to reduce. The relation is defined as the smallest congruence relation on sensors (and 
programs) closed under the rules given in Figure |3] 

The parallel composition operators for programs and for sensors are taken to be commutative and 
associative with idle and off as their neutral elements, respectively (vide Rules S -MONOID-PROGRAM 
and S-MONOID-Sensor). Rule S-idle-SEQ asserts that idle is also neutral with respect to sequential 
composition of programs. Rule S-PROGRAM-STRU incoiporates structural congruence for programs into 
sensors. When a sensor is broadcasting a message it uses a bag to collect the sensors as they become 
engaged in communication. Rule S -BROADCAST allows for a sensor to start the broadcasting operation. 
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M{k) = {X,)P, b > Cin 



[this./,[^l ; Pi\P2,Mr/ [Pi[v/x,] ; A | P2 , M] ^'^^^ 
k dom(M) 

[this .k[v] ; Pi I P2, Mjl'' -^F [this .k[v] ; Pi | P2, M]^'" 



d(p,/)<r > Cout 



[net .k[v] ; A | P2, M]f'^{5} | [P', MX/'' 

[net.k[v] ; Pi|P2,M]|:''^{5|[P'|this./,[T;],MX''"} 

[net ./.[t;] ; Pi | P2, MlP-'-j^} [Pi | P2, MJ^^^^^ | 5 

b > C|n 

[install M' ■ Pi I P2, M]^''' -^f [Pi | P2, M + MXi'c,„ 

^ > Cin 



[sense (f) in P ; Pi | P2, M]^''^ ^f [P[P(p)/x] ; Pi | P2, M] 



p,r 
b-c-,„ 



Si 



>F J2 



S I 5*1 — >i;' 5" I 5*2 



Dl = D2 J2 J3 ^3 = ^4, 

Si — >F »S'4 

S — >F S' 



(R-method) 
(r-no-method) 
(r-broadcast) 



(R-RELEASE) 
(R-INSTALL) 

(R-SENSE) 



5, P ^ S' F 



(R-PARALLEL, R-STRUCTURAL) 



(R-NETWORK) 



Fig. 4. Reduction semantics for processes and networks. 



A terminated sensor is a sensor with insufficient battery capacity for performing an internal or an external 
reduction step (vide Rule S-BAT-EXHAUSTED). 

The reduction relation on networks, notation S,F — > S',F, describes how sensors S can evolve 
(reduce) to sensors S", sensing the field F. The reduction is defined on top of a reduction relation for 
sensors, notation 5 — >i? S", inductively defined by the rules in Figure ID The reduction for sensors is 
parametric on field F and on two constants Cin and Cout that represent the amount of energy consumed 
when performing internal computation steps (cin) and when broadcasting messages (Cout)- 

Computation inside sensors proceeds by invoking a method (either local — Rules R-METHOD and R- 
NO-METHOD — or remote — Rules R-BROADCAST and R-RELEASE), by sensing values (Rule R-SENSE), 
and by updating the method collection of the sensor (Rule R-INSTALL). 
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The invocation of a local method /j with arguments v evolves differently depending on whether or 
not the definition for li is part of the method collection of the sensor. Rule R-METHOD describes the 
invocation of a method from module M, defined as M{li) = {xi)Pi. The result is the program Pi where 
the values v are bound to the variables in x. When the definition for li is not present in M, we have 
decided to actively wait for the definition (see Rule R-NO-METHOD). Usually invoking an undefined 
method causes a program to get stuck. Typed programming languages use a type system to ensure that 
there are no invocations to undefined methods, ruling out all other programs at compile time. At run- 
time, another possible choice would be to simply discard invocations to undefined methods. Our choice 
provides more resilient applications when coupled with the procedure for deploying code in a sensor 
network. We envision that if we invoke a method in the network after some code has been deployed (see 
Example IIII-Db . there may be some sensors where the method invocation arrives before the deployed 
code. With the semantics we propose, the call actively waits for the code to be installed. 

Sensors communicate with the network by broadcasting messages. A message consists of a remote 
method invocation on unspecified sensors in the neighborhood of the emitting sensor. In other words, 
the messages are not targeted to a particular sensor (there is no peer-to-peer communication). The 
neighborhood of a sensor is defined by its communication radius, but there is no guarantee that a message 
broadcasted by a given sensor arrives at all surrounding sensors. There might be, for instance, landscape 
obstacles that prevent two sensors, otherwise within range, from communicating with each other. Also, 
during a broadcast operation the message must only reach each neighborhood sensor once. Notice that we 
are not saying that the same message can not reach the same sensor multiple times. In fact it might, but as 
the result of the echoing of the message in subsequent broadcast operations. We model the broadcasting 
of messages in two stages. Rule R-BROADCAST invokes method li in the remote sensor, provided that the 
distance between the emitting and the receiving sensors is less that the transmission radius (d(p,p') < r). 
The sensor receiving the message is put in the bag of the emitting sensor, thus preventing multiple 
deliveries of the same message while broadcasting. Observe that the rule does not enforce the interaction 
with all sensors in the neighborhood. Rule R-RELEASE finishes the broadcast by consuming the operation 
(net .Zj [{/]), and by emptying out the contents of the emitting sensor's bag. A broadcast operation starts 
with the application of Rule S-BROADCAST, proceeds with multiple (eventually none) applications of 
Rule R-BROADCAST (one for each target sensor), and terminates with the application of Rule R-RELEASE. 

Installing module M' in a sensor with a module M, Rule R-INSTALL, amounts to add to M the methods 
in M' (absent in M), and to replace (in M) the methods common to both M and M' . Rigorously, the 
operation of installing module M' on top of M, denoted M + M', may be defined as M + M' = 
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(M \ M') U M'. The + operator is reminiscent of Abadi and Cardelli's operator for updating methods 
in their imperative object calculus [?]. 

A sensor senses the field in which it is immersed, Rule R-SENSE, by sampling the value of the field 
F in its position p and, continues the computation replacing this value for the bound variables x in 
program P. 

Rule R-PARALLEL allows reduction to happen in networks of sensors and Rule R-STRUCTURAL brings 
structural congruence into the reduction relation. 

D. The Operational Semantics Illustrated 

To illustrate the operational semantics of CNS, we present the reduction steps for the examples 
discussed at the end of Section III-BI During reduction we suppress the side annotations when writing 
the sensors. Due to space constraints we consider a rather simple network with just the sink and another 
sensor. 

[ net . sample [], MSink (p ,r )] | [ idle , MSensor(pi,ri) ] 

We assume that the sensor is within range from the sink and vice-versa. This network may reduce as 
follows: 
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[net.sample[],MSink(p,r)] | [idle,MSensor(pi,ri)] = 
[net.sample[],MSink(p,r)]{off} | [idle,MSensor(pi,ri)] 



(S-BROADCAST) 



(d(p,pi) < r, R-BROADCAST, S-MONOID-SENSOR) 

[net.sample[],MSink(p,r)] {[this.sample[] || idle,MSensor(pi,ri)]} ^= 

(R-release, S-monoid-Program) 



[idle,MSink(p,r) 
[idle,MSink(p,r) 
[idle,MSink(p,r) 
[idle,MSink(p,r) 
[idle,MSink(p,r) 



[this.sample[],MSensor(pi,ri)] (R-method) 

[net.sample[]; sense x in net.forward[pi,x],MSensor(pi,ri)] = (S-broadcast) 

[net.sample[]; sense x in net.forward[pi,x],MSensor(pi,ri)]{off} (R-release) 

[sense x in net.forward[pi,x],MSensor(pi,ri)] (R-sense) 
[net.forward[pi,i^(pi)], MSensor(pi,ri)] = (S-monoid-Sensor) 

[net.forward[pi,F(pi)], MSensor(pi,ri)] | [idle,MSink(p,r)] = (S-broadcast) 
[net.forward[pi,F(pi)], MSensor(pi,ri)]{off} | [idle,MSink(p,r)] —>■= 

(d(pi,p) < ri, R-BROADCAST, S-MONOID-SENSOR) 

[net.forward[pi,F(pi)], MSensor(pi,ri)]{[this.forward[pi,i^(pi)] || idle, MSink(p,r)]} —^= 

(R-RELEASE, S-MONOID-PROGRAM) 



[idle, MSensor(pi,ri)] | [this.forward[pi,F(pi)], MSink(p,r)] 

[idle, MSensor(pi,ri)] | [log_position_and_value[pi,-F(pi)], MSink(p,r)] ■ 

[log_position_and_value[pi,F(pi)] | [idle, MSensor(pi,ri)], MSink(p,r)] 



(R-METHOD) 

(S-monoid-Sensor) 



So, after these reduction steps the sink gets the field values from the sensor at position pi and logs them. 
The sensor at pi is idle waiting for further interaction. 

Following we present the reduction step for our second (and last) example of Section III-BI where we 
illustrate the broadcast, the deployment, and the installation of code. Again, due to space restrictions, we 
use a very simple network with just the sink and another sensor, both within reach of each other. 
[ net . deploy [M] ; net . seal [], MSink(p , r ) ] | [ idle , MSensor(pi,ri)] 
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This network may reduce as follows: 

[net.deploy[M]; net.seal [], MSink(p,r)] | [idle,MSensor(pi,ri)] = (S-broadcast) 
[net.deploy[M]; net.seal [], MSink(p,r)]{off} | [idle,MSensor(pi,ri)] ^= 

(d{p,pi) < r, R-BROADCAST, S-MONOID-SENSOR) 

[net.deploy[M]; net.seal [], MSink(p,r)] | {[this.deploy[M] || idle, MSensor(pi,ri)]} ^= 

(R-release, S-monoid-Program) 

[net. seal [], MSink(p,r)] | [this.deploy[M], MSensor(pi,ri)] ^ (R-method) 

[net.seal [], MSink(p,r)] | [net.deploy[M]; install M, MSensor(pi,ri)] = (S-broadcast) 

[net. seal [], MSink(p,r)] | [net.deploy[M]; install M, MSensor(pi,ri)]{off} 

(R-RELEASE, S-MONOID-SENSOR) 

[net.seal [], MSink(p,r)] | [install M, MSensor(pi,ri)] ^ (R-install) 

[net.seal [], MSink(p,r)] | [idle, MSensor(pi,ri)+M] = (S-broadcast) 

[net.seal [], MSink(p,r)]{off} | [idle, MSensor(pi,ri)+M] ^= 

(d{p,pi) < r, R-broadcast, S-monoid-Sensor) 

[net.seal [], MSink(p,r)] {[this. seal [] || idle, MSensor(pi,ri)+M]} — >= 

(R-RELEASE, S-MONOID-PROGRAM) 



[idle,MSink(p,r)] 
[idle,MSink(p,r)] 
[idle,MSink(p,r)] 

[idle,MSink(p,r)] 
[idle,MSink(p,r)] 



[this. seal [], MSensor(pi,ri)+M] -> (R-method) 
[net.seal []; install {deploy = () idle}, MSensor(pi,ri)+M] = (S-broadcast) 
[net.seal []; install {deploy = () idle}, MSensor(pi,ri)+M]{off} ^= 

(R-RELEASE, S-MONOID-SENSOR) 

[install {deploy =0 idle}, MSensor(pi,ri)+M] ^ (R-install) 
[idle, MSensor(pi,ri)+M+{deploy = () idle}] 



After these reductions, the sink is idle after deploying the code to the sensor at p. The sensor at p 
is also idle, waiting for interaction, but with the code for the module M installed and with the deploy 
method disabled. 
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III. Programming Examples 

In this section we present some examples, programmed in CSN, of typical operations performed on 
networks of sensors. Our goal is to show the expressiveness of the CSN calculus just presented and 
also to identify some other aspects of these networks that may be interesting to model. In the following 
examples, we denote as MSensor and MSink the modules installed in any of the anonymous sensors in 
the network and the modules installed in the sink, respectively. Note also that all sensors are assumed to 
have a builtin method, deploy, that is responsible for installing new modules. The intuition is that this 
method is part of the tiny operating system that allows sensors to react when first placed in the field. 
Finally, we assume in these small examples that the network layer supports scoped flooding. We shall 
see in the next section that this can be supported via software with the inclusion of state in sensors. 

A. Ping 

We start with a very simple ping program. Each sensor has a ping method that when invoked calls 
a method forward in the network with its position and battery charge as arguments. When the method 
forward is invoked by a sensor in the network, it just triggers another call to forward in the network. 
The sink has a distinct implementation of this method. Any incomming invocation logs the position and 
battery values given as arguments. So, the overall result of the call net. ping [] in the sink is that all 
reachable sensors in the network will, in principle, receive this call and will flood the network with their 
positions and battery charge values. These values eventually reach the sink and get logged. 

MSensor (p,b) = { 

ping = net . forward [p, b] ; net.ping[] 

forward = (x,y) net . forward [x , y] 

} 

MSink(p,b) = { 

forward = (x,y) log_position_and_power [x , y ] 

} 

[net. ping [] , MSink(p,6)] | 

[idle, MSensor (pi ,61 )] ^^^'"-^ | ... | [idle, MSensor (p„,6„) ] 

B. Querying 

This example shows how we can program a network with a sink that periodically queries the network 
for the readings of the sensors. Each sensor has a sample method that samples the field using the sense 
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construct and calls the method forward in the neighbourhood with its position and the value sampled as 
arguments. The call then queries the neighbourhood recursively with a replica of the original call. The 
original call is, of course, made from the sink, which has a method start.sample that calls the method 
sample in the network within a cycle. Note that, if the sink had a method named sample instead of 
start_sample, it might get a call to sample from elsewhere in the network that could interfere with the 
sampling conlrol cycle. 
MSensor(p) = { 

sample = () sense (x) in net. forward [p, x]; net. sample [] 

forward = (x, y) net . forward [x , y] 

} 

MSink(p) = { 

start_sample = () net . sample [] ; this . start_sample [] 
forward = (x, y) log_position_and_value [x , y ] 

} 

[this . start. sample [] , MSink(p)] ^'"^ | 

[idle, MSensor(pi)] ^^^■'■1 | ... | [idle, MSensor(p„)] p;;"" 



C. Polling 

In this example the cycle of the sampling is done in each sensor, instead of in the sink, as in the 
previous example. The sink just invokes the method start_sample once. This method propagates the call 
through the network and invokes sample, for each sensor. This method samples the field, within a cycle, 
and forwards the result to the network. This implementation requires less broadcasts than the previous 
one as the sink only has to call start_sample on the network once. On the other hand, it increases the 
amount of processing per sensor. 

MSensor(p) = { 

start_sample = () net . start.sample [] ; this . sample [] 

sample = () sense (x) in net.forward[p, x]; this . sample [] 

forward = (x, y) net . forward [x , y] 

} 

MSink(p) = { 

forward = (x, y) log_position_and_value [x , y ] 

} 

[net. start_example [] , MSink(p)] l'"" \ 
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[idle, MSensor(pi)] ^^^''■^ | ... | [idle, MSensor(p„)] p-'^" 



D. Code deployment 

The above examples assume we have some means of deploying the code to the sensors. In this example 
we address this problem and show how it can be programmed in CSN. The code we wish to deploy 
and execute is the same as the one in the previous example. To achieve this goal, the sink first calls 
the deploy method on the network to install the new module with the methods start_sample, sample and 
forward as above. This call recursively deploys the code to the sensors in the network. The sink then calls 
start_sample to start the sampling, again as above, and waits for the forwarded results on the method 
forward. 

MSensor(p) = { 

deploy = (x) install x; net . deploy [x] 

} 

MSink(p) = { 

forward = (x,y) log_position_and_value [x , y] 

} 

[net.deploy[{ 

start_sample = () net . start.sample [] ; this . sample [] 

sample = () sense (x) in net. forward [p, x]; this . sample [] 

forward = (x, y) net . forward [x , y] 

}]; 



net . start-sample [] , MSink(p)] j^'' 



b 

[idle, MSensor(pi)] P^^''^ | ... | [idle, MSensor(p„)] 



A refined version of this code, one that avoids the start_sample method completely, can be programmed. 
Here, we deploy the code for all sensors by sending methods sample and forward to all the sensors in 
the network by invoking deploy. Once deployed, the code is activated with a call to sample in the sink, 

instead of using the start_sampl8 method as above. 



MSensor(p) = { 

deploy = (x) install x; net . deploy [x] 

} 

MSink(p) = { 

forward = (x,y) log_position_and_value [x , y] 
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} 

[net.deploy[{ 
sample 



net . sample [ ] ; 

install {sample = () sense (x) in net . forward [p , x]; 

this . sample [] } ; 

this . sample [] 
(x, y) net . forward [x , y] 



forward 



}]; 

net. sample [] , MSink(p)] \ 
[idle , MSensor(pi)] H^''^ \ ... 



I [idle, MSensor(p„)]^_ 



Notice that the implementation of the method sample has changed. Here, when the method is executed 
for the first time at each sensor, it starts by propagating the call to its neighborhood and then, it changes 
itself through an install call. The newly installed code of sample is the same as the one in the first 
implementation of the example. The method then continues to execute and calls the new version of 
sample, which starts samphng the field and forwarding values. 

E. Sealing sensors 

This example shows how we can install a sensor network with a module that contains a method, seal, 
that prevents any further dynamic re-programming of the sensors, preventing anyone from tampering 
with the installed code. The module also contains a method, unseal that restores the original deploy 
method, thus allowing dynamic re-programming again. The sink just installs the module contaimung 
these methods in the network by broadcasting a method call to deploy. Each sensor that receives the call, 
installs the module and floods the neighborhood with a replica of the call. Another message by the sink 
then replaces the deploy method itself and re-implements it to idle . This prevents any further instalation 
of software in the sensors and thus effectively seals the network from external interaction other than the 
one allowed by the remainder of the methods in the modules of the sensors. 

MSensor = { 

deploy = (x) install x; net . deploy [x] 



} 



MSink 



= { } 



[net. deploy[{ 



unseal 



seal 



= install {deploy = () idle} 

= install {deploy = (x) install x; net . deploy [x]} 
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}]; 

net. seal [] , MSink] \ 

[idle, MSensor] ^^^''■1 | ... | [idle, MSensor]^^ 



IV. Discussion 

In the previous sections, we focused our attention on the programming issues of a sensor network 
and presented a core calculus that is expressive enough to model fundamental operations such as local 
broadcast of messages, local sensing of the environment, and software module updates. CSN allows the 
global modeling of sensor networks in the sense that it allows us to design and implement sensor network 
applications as large-scale distributed applications, rather than giving the programmer a sensor-by-sensor 
view of the programming task. It also provides the tools to manage running sensor networks, namely 
through the use of the software deployment capabilities. 

There are other important features of sensor networks that we consciously left out of CSN. In the 
sequel we discuss some of these features and sketch some ideas of how we would include support for 
them. 

a) State: From a programming point of view, adding state to sensors is essential. Sensors have some 
limited computational capabilities and may perform some data processing before sending it to the sink. 
This processing assumes that the sensor is capable of buffering data and thus maintain some state. In a 
way, CSN sensors have state. Indeed, the atributes p, b, and r may be viewed as sensor state. Since these 
are characteristic of each sensor and are usually controlled at the hardware level, we chose to represent 
this state as parameters of the sensors. The programmer may read these values at any time through builtin 
method calls but any change to this data is performed transparently for the programmer by the hardware 
or operating system. As we mentioned before, it is clear that the value of b changes with time. The 
position p may also change with time if we envision our sensors endowed with some form of mobihty 
(e.g., sensors dropped in the atmosphere or flowing in the ocean). 

To allow for a more systematic extension of our sensors with state variables we can assume that each 
sensor has a heap H where the values of these variables are stored: [H, P, M]^''^. The model chosen 
for this heap is orthogonal to our sensor calculus and for this discussion we assume that we enrich the 
values V of the language with a set of keys, ranged over by k. Our heap may thus be defined as a map H 
from keys into values. Intuitively, we can think of it as an associative memory with the usual built-in 
operations put, get, lookup, and hash. Programs rumung in the sensors may share state by exchanging 
keys. We assume also that these operations are atomic and thus no race conditions can arise. 
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With this basic model for a heap we can re-implement the Ping example from Section IIII-AI with 
scoped flooding thus eliminating echos by software. We do this by associating a unique key to each 
remote procedure call broadcast to the network. This key is created through the built-in hash function 
that takes as arguments the position p and the battery b of the sensor. Each sensor, after receiving a call 
to ping, propagates the call to its neighborhood and generates a new key to send, with its position and 
battery charge, in a forward call. Then, it stores the key in its heap to avoid forwarding its own forward 
call. On the other hand, each time a sensor receives a call to forward, it checks whether it has the key 
associated to the call in its heap. If so, it does nothing. If not, it forwards the call and stores the key in 
the heap, to avoid future re-transmission. 

MSensor(p, b) = { 

ping = net . ping [] ; 

let k = hash[p,b] in net . forward [p , b, k]; 
put[k,.] 

forward = (x, y, k) if ( ! lool<up [ k ] ) then 

net . forward [x , y, k]; 
put[k,_] 

} 

MSink(p, b) = {...} 
[net. ping [] , MSink] l'' \ 

[idle, MSensor(pi,6i)] ^^''■^ | ... | [idle, MSensor(p„,6„)] ^J;;'''" 



b) Events: Another characteristic of sensors is their modus operandi. Some sensors sample the field 
as a result of instructions implemented in the software that controls them. Such is the case with CSN 
sensors. The programmer is responsible for controlling the sensing activity of the sensor network. It is 
of course possible for sensor nodes to be activated in different ways. For example, some may have their 
sensing routines implemented at hardware or operating system level and thus not directly controllable 
by the programmer. Such classes of sensor nodes tipically sample the field periodically and are activated 
when a given condition arises {e.g., a temperature above or below a given threshold, the detection of 
CO2 above a given threshold, the detection of a strong source of infrared light). The way in which 
certain environmental conditions or events can activate the sensor is by triggering the execution of a 
handler procedure that processes the event. Support for this kind of event-driven sensors in CSN could 
be achieved by assuming that each sensor has a builtin handler procedure, say Inandle, for such events. 
The handler procedure, when activated, receives the value of the field that triggered the event. Note that. 
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from the point of view of the sensor, the occurrence of such an event is equivalent to the deployment 
of a method invocation this.handle[v] in its processing core, where v is the field value associated with 
the event. The sensor has no control over this deployment, but may be programmed to react in different 
ways to these calls, by providing adequate implementations of the handle routine. The events could be 
included in the semantics given in Section III-CI with the following rule: 

[P, M]P/ -^F [this .handle [F{p)] \ P, Mf/ (R-event) 

As in the case of the builtin method for code deployment, the handler could be programmed to change 
the behavior of the network in the presence of events. One could envision the default handler as 
handle = (x) idle, which ignores all events. Then, we could change this default behavior so that an event 
triggers an alarm that gets sent to the sink. A possible implementation of such a dynamic re-programming 
of the network default handlers can be seen in the code below. 

MSensor(p) = { handle = (x) idle } 
MSink(p) = { handle = (x) idle } 
[ net . deploy [{ 

handle = (x) net . alarm [p, x] 

alarm = (x,y) net . alarm [x , y] 

}]; 

install {alarm = (x,y) s i ng _be 1 1 [x , y ] } , 
MSink(p)] r I 

[idle, MSensor(pi)] P^^-''^ | ... | [idle, MSensor(p„)] r:'''" 

where the default implementation of the handle procedure is superseded by one that eventualy triggers 
an alarm in the sink. 

More complex behavior could be modeled for sensors that take multiple readings, with a handler 
associated with each event. 

c) Security: Finally, another issue that is of outmost importance in the management of sensor 
networks is security. It is important to note that many potential applications of sensor networks are in 
high risk situations. Examples may be the monitorization of ecological disaster areas, volcanic or sismic 
activity, and radiation levels in contaminated areas. Secure access to data is fundamental to establish its 
credibility and for correctly assessing risks in the management of such episodes. In CSN we have not 
taken security issues into consideration. This was not our goal at this time. However, one feature of the 
calculus may provide interesting solutions for the future. In fact, in CSN, all computation within a sensor 
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results from an invocation of methods in the modules of a sensor, either originating in the network or 
from within the sensor. In a sense the modules M of the sensor work as a firewall that can be used to 
control incomming messages and implement security protocols. Thus, all remote method invocations and 
software updates might first be validated locally with methods of the sensor's modules and only then the 
actions would be performed. The idea of equipping sensors, or in general domains, with some kind of 
membrane that filters all the interactions with the surrounding network has been explored, for instance, 
in [?], in the M-calculus [?], in the Kell calculus [?], in the Brane calculi [?], in Miko [?], and in [?]. 
One possible development is to incorporate some features of the membrane model into CSN. The current 
formulation of the calculus also assumes that all methods in the module M of a sensor [P, M]f^'^ are 
visible from the network. It is possible to implement an access policy to methods in such a way that 
some methods are private to the sensor, i.e., can only be invoked from within the sensor. This allows, 
for example, the complete encapsulation of the state of the sensor. 

V. Conclusions and Future Work 

Aiming at providing large-scale sensor networks with a rigorous and adequate programming model 
(upon which operating systems and high-level programming languages can be built), we presented CSN 
— a Calculus for Sensor Networks, developed specifically for this class of distributed systems. 

After identifying the necessary sensing, processing, and wireless broadcasting features of the calculus, 
we opted to base our work on a top-layer abstraction of physical and link layer communication issues (in 
contrast with previous work on wireless network calculi [?, ?]), thus focusing on the system requirements 
for programming network-wide applications. This approach resulted in the CSN syntax and semantics, 
whose expressiveness we illustrated through a series of implementations of typical operations in sensor 
networks. Also included was a detailed discussion of possible extensions to CSN to account for other 
important properties of sensors such as state, samphng strategies, and security. 

As part of our ongoing efforts, we are currently using CSN to establish a mathematical framework for 
reasoning about sensor networks. One major objective of this work consists in providing formal proofs 
of correctness for data gathering protocols that are commonly used in current sensor networks and whose 
performance and reliability has so far only been evaluated through computer simulations and ad-hoc 
experiments. 

From a more practical point of view, the focus will be set on the development of a prototype 
implementation of CSN. This prototype will be used to emulate the behavior of sensor networks by 
software and, ultimately, to port the programming model to a natural development architecture for sensor 
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network applications. 
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